1. Field of the Invention
The present invention is directed to a system for mapping objects and their associations to and from a relational database and, more particularly, to a system that uses a reflection layer, mapping files, overflow tables and buffered database input/output to provide flexibility and performance improvements in high volume transaction situations.
2. Description of the Related Art
A recurring problem in object development is how to insert or retrieve an object from a relational database table without hard-coding the object's structure and the database function calls. Objects can contain basic types as attributes (for example dates, strings, etc.) which map directly to the database, but they can also contain other objects, pointers to objects and lists, which may need mapping to multiple tables. Complex inheritance structures complicate the mapping issues. Hard-coding a solution, as seen in many systems, results in difficult to maintain and unwieldy database interfaces. What is needed is an object to relational database mapping infrastructure.
Another problem is how to store objects that are contained within lists in a parent object. A possible approach is to store the list object in a separate table and associated to the parent object using foreign key relationship. This approach does not provide the performance necessary for high volume data processing since for each object containing an object list, a second table needs to be accessed. Another possible approach is to store the list objects within the parent object's storage table. This results in having to provide columns to store all possible entries. This results in large storage tables within many of the columns remaining empty when the lists are not full. What is needed is a system which will allow storage of an optimum number of list entries within the parent object's table. The optimum number has to be determined on a case by case basis and solely depends on the business scenario. For example, a scenario where 96% of all customers of a telecommunication company are estimated to have one or two accounts, the remaining 4% have an average of 6 accounts. In this scenario, two might be the optimal number to provide fast access for 96% of the customer retrievals and not to allocate storage for more accounts that are not used by 96% of the customers in the database.